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This article describes the Top Down Implementation Han used by the Operations Sus- 
taining Engineering Section for the development of System P&formance Test software 
during the Mark IV-A era. The plan is based upon the identification of the hierarchical 
relationship of the individwd elements of the software design^ the development of a 
sequence of functionally oriented demonstrable steps, the allocation of subroutines to 
the specific step where they are first required, and objective status reporting. The results 
are meaningful determination of milestones, improved managerial visibility, better project 
control, and ultimately a successful software development. 


I. Introduction 

The Mark IV-A era represents significant changes in the 
operating environment and the hardware configuration within 
the DSN. System Performance Test (SPT) software will be 
needed to test and verify the operational integrity of the DSN 
during the Mark IV-A implementation. 

The SPT software package being developed by the Opera- 
tions Sustaining Engineering Section will consist of a test exec- 
utive and a set of seven applications tasks. Basically, the exec- 
utive distributes input data to the applications, provides 
resource allocation services, and performs common processing 
functions such as dumping, display generation, and test proce- ' 
dure reading. The application tasks are each designed to test a 
particular system. Tracking, Telemetry, Command, Monitor 
and Control, Very Long Baseline Interferometry, Radio 
Science, and Frequency and Timing will all be supported by 
SPT software for the Mark IV-A configuration. 

The SPT software will reside in the System Performance 
Test Assembly (SPTA). The SPTA, which also serves as the 


backup Complex Monitor and Control (CMC) computer, will 
be a Modcomp Classic 7345. The operating system will be a 
m( dified version of the MAX IV Operating System supplied 
by the computer manufacturer. 

The software development effort for the Mark IV-A Proj- 
ect, summarized above, represents the largest project under- 
taken by the SPT Software Support Group. To achieve the 
technical, budgetary, and scheduling goals of the project, a 
top down implementation plan has been created that always 
develops and maintains the SPT system in a continually 
cycling, demonstrable fashion. It is the intent of this paper to 
describe the history, justification, and components of the SPT 
implementation plan. 

II. Background 

The success of large software development efforts has 
improved throughout the industry. These improvements are 
largely attributable to the application of a technological wave 
of new approaches that have been loosely referred to as 
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structured programming. More explicitly, the new technologies 
include replacement of flowcharts via usage of design lan- 
guages, elimination of the GOTO by confinement to a small 
complete set of logical constructs, increased emphasis and 
formalization of the role of the programmi ng support librar- 
ian, increased emphasis on reviews via usage of either struc- 
tured walk-throughs or inspection teams, and a reorganization 
of programming personnel into the chief programmer team 
formation. Unfortunately, despite the considerable progress 
that has been made, many projects still fail to meet their 
schedule, have cost overruns, and the end product never 
quite operates as reliably as intended. In any event, even for 
supposedly successful projects, the cost of software is still 
too high. 

A rnajc; reason for these continuing software difficulties 
and continued high costs, despite advances in technique, is 
that the impact of the aforementioned technical advances 
is limited when constrained by the effects of traditional 
management techniques. All of the previously mentioned 
structured progremming techniques deal with the program- 
mer and programming. None deal directly with the issues 
of planning and managing a large-scale software development. 
The industry is generally using the same planning and man- 
aging approaches it has always used, and these have fre- 
quently proven to be unsuccessful. The result is that the 
manager continues to have little visibility and little effective 
control over the developing system. If the manager had a 
mechanism that permitted him to arrive at a meaningful 
implementation plan; permitted him to objectively assess 
the project's status as it developed; provided him clear visi- 
bility of the development activity; considered cost, schedule, 
manpower and the chosen design, then the manager would 
be in a position to truly manage the project and lead it to 
a successful conclusion at minimal cost. 


The SPT top down implementation plan fills this gap. The 
SPT plan is to management what structured programming is 
to the programmer. As with structured programming, which is 
complemented by the SPT plan, the SPT plan improves visibil- 
ity, meaningfulness and orderliness. It allows the manager to 
start the project off on the right path, closely monitor the 
software development as it progresses, and ultimately to bring 
the project to the desired successful conclusion. 


III. Implementation Plan Selection Crtteria 

The top down method appears to have been first espoused 
by Dr. 11. D. Mills of IBM. Though this discu''>sion. ami other 
discussions in the computing literature, advocated top di^wn 


implementation, little advice was presmted on how to phn a 
top down implementation. Stating that a computer program 
should be .mp^ented in a top down secpience is insufficient 
for a large software development. Due to the complexity of 
its hierarchical structure, literally thousands of top down 
implementation sequences may be possible. Thus, selecting 
the proper top down implementation sequence becomes a 
very significant issue. 

For example, one could implement all the subroutines at 
a particular level for the entire system, foUowed by all the 
subroutines at the next level across the system, and so on, 
until finally the bottom level subroutines are Implemented. 
There are those in the industry who advocate this sequence. 
This would be top down, but in our opinion, represents an 
inferior implementation sequence. This is because bottom level 
subroutines usually are required to provide a demonstration of 
a complete operational .>y$tem function. Thus, for most of the 
system's development, very few operational functions would 
be deiuonstrabie. However ^arly functional demonstrability is 
one of the main benefits ,hat should be achieved from top 
down implementation. Alternatively, many top down se- 
quences might conflict with expected equipment delivery 
dates. 

Thus, selecting the most appropriate top down implementa- 
tion sequence is an important issue. Hie SPT plan is using a 
comprehensive methodology which has been developed for 
creating and maintaining an optimal top down implementa- 
tion plan. This technique provides broad benefits to the 
ensuing software development. 


IV. Top Down Concepts 

Top down design refers to a method of designing a compu- 
ter program wherein higlier level or calling segments are 
designed before lowei level or called segments. This do^ not 
mean that all segments .*it one level must be designed, or 
named, before creating the viesign, or name, of any segments 
at the next level. It means that if one were to consider the 
system's subroutine hierarchy as a treelike structure, then 
along each branch of the tree, mbroutincs are defined and 
chosen for design, starting from ti e top of the hierarchy and 
working down. 


Top down implementation refers to the development of a 
computer program in a downward hierarchica] sequence along 
each branch of the program's subroutine hierarchy. Design, 
documentation, coding, integration and testing usually arc 
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concurrently performed on different portions of the develop- 
ing system. In a top down sequence, these are performed alung 
each branch simultaneou .y under development. 


V. Preparation of ttieSFT Top Down 
Implementation Plan 

A viable software implementation plan can only be pre- 
pared after a sufficient quantity of system analysis activities 
have occurred and before the detailed implementation has 
begun. The plan is then used to launch the implementation 
phase for a large-scale software development, in operation, 
the SPT approach is based upon the utilization and interplay 
of three documents. They are the Subroutine Hierarchy, the 
Network of Demonstrable Functions (NDF), and the Software 
Status Report. 

In a nutshell, the Subroutine Hierarchy represents a design 
abstract for the computer software. The Network of Dimon- 
strable Functions represents a functional abstract of the opera- 
tional system. The Softwaie Status Report relates the software 
design to the NDF system functions for the purpose of sched- 
uling tlie software and maintaining the status of software 
development. The main point of this nutshell description is 
that attentive preparation of these documents results in a 
meaningful schedule that allows management to have real 
visibility in areas such as the software's true status, cost to 
completion, and time to completion. 

VI. Subroutine Hierarchy 

The Subroutine Hierarchy is a high-level representation of 
the structure of the hierarchical design of the computer pro- 
gram. It readily conveys a high-level image of the design being 
represented, showuig all of the parts constituting the design, 
their hierarchical rclationsliip to each other, their categories 
and, to a degree, their functions. All of the segments must 
represent small subroutines, perhaps averaging 25 to 50 
lughcr-ordcr language statements. 

The Subroutine Hierarchy evolves as the design and the 
software evolve. Initially, when the implementation plan is 
first prepared, the Subroutine Hierarchy represents the inten- 
ded design structure of the computer piogram. At completion 
of the software developincnl, it represcnls the actual structure 
of the computer program At all intermediate stages, it is kept 
current and represents the currenii> proiccled siructure of the 
program. 

fur a laigc computer program, with perhaps one thousand 
or more subroutines, the subroutines may be treated in a 
statistical manner foi the purposes of making estimates. 


schedules and plans This is one of the principles of the SPT 
approach. Namely, by partitioning a large computer program 
into its elemental pieces (subroutines), the effects of isdated 
misjudgement (e.g., size or complexity) relative to any indi* 
vidual subroutine tend to average out over the total program 
development, and do not affect the overall outcome. The 
effect of frequent misjudgement of the same characteristic of 
many subroutines (e.g., development time) tends to become 
quickly apparent and serves as a reliable indicator of develop- 
ment trends and ultimate results (if not corrected). 

The Subroutine Hierarchy enables the software designers to 
conveniently conceptualize about the program and its parts, 
and to visualize the hierarchical organization of the program. 
It communicates in an overall conceptual maimer the struc- 
ture of the design. It is the essential design element, repre- 
senting the components of the program's design for the pur- 
pose of plaiming and tracking the implementation of that 
design. It thus becomes the primary determinant in estimates 
oi ost and memory size for the computer program. 

Figure 1 shows a portion of the subroutine hierarchy for 
the SPT Project. Due to the large number of subroutines, the 
hierarchical structure is represented in a horizontal rather 
than vertical (or treelike) manner. Varying hierarchical levels 
are represented by varying levels of indentation. The hierarchy 
identifies both the symbolic name and descriptive name of 
the subroutine. It identifies the particular step in the SPT 
impleinentation plan where the subroutine will be first 
required. (The next section will elaborate on the definition 
of steps.) Only the first occurrence of a subroutine in the tree 
is expanded to the bottom level. Subsequent occurrences of 
any subroutine use a reference number to identify the line 
number of the fir.s^ occurrence. If the subroutine itself invokes 
other subroutines, an asterisk is used to indicate the full 
expansion can be found at that first occurrence. 

VII. Network of Demonstrable Functions 

The Structure of the software design and the identification 
of the constituent subroutines have been described as part 
of preparing the Subroutine Hierarchy. No discussion has yet 
occurred relative to the development sequence of these sub- 
routines. nor relative to the individual milestones that wilt be 
scheduled and tracked during the development. This is where 
the NDF comes into play. 

The .NDF is that part of the SPT implementation plan tliat 
identifies the individual increments, or steps, and the sequence 
of development for those steps. The steps arc scheduled, 
developed, tracked, integrated, tested and eventually internal!) 
accepted- In other words, on the surface it is a **Perl-like net- 
work." Beneath the surface there are a number of aspects of 


192 



the NDF that must be explained before its value can be fully 
grasped. 

First of all, the NDF must be created by personnel that 
have an in*depth functional understanding of the application, 
its requirements, and the expected operational characteristics 
of the system. The personnel assigned to the NDF task will 
have acquired the necessary knowledge as a result of their 
prior system analysis activities. If they do not have this know- 
ledge, they must first acquire it before they can hope to create 
a meaningful, detailed, functionally oriented plan of demon- 
strable steps. 

Secondly, the NDF steps are oriented towards functions 
from the user's standpoint, not from the programmer's stand- 
point. For example, ^"output directive/menu index" is a typi- 
cal step. This is as opposed to "build test contiguration table," 
which would occur internally within the computer and not 
provide the user direct observation of the step having oc- 
curred. On the other hand, a step such as "print test configur- 
ation table" could be demonstrated to the user. Successful 
demonstration of this would imply successful construction 
of the test configuration table. 

This leads us into the third important aspect of the NDF. 
To the maximum extent possible, steps of the NDF should be 
readily demonstrable to an observer who is not a programmer. 
Those few steps that are not readily demonstrable to such an 
observer must, nevertheless, still be demonstrable. This demon- 
strability is the only basis upon which an objective determina- 
tion can be made as to the completion of the step. 

The principle of denionstrability leads us to a fourth 
important aspect of the NDF. The development sequence of 
demonstrable steps must correspond to a natural functional 
sequence of increasing functional capability. To put it another 
way, Irom the user's operational standpoint, it must be a 
sequence which demonstrates "first things first." 

A fifth important aspect of the NDF is that the steps must 
each add on to an already cycling system. Each new step must 
be directly integrated into the cycling system, producing a 
continuously increasing functional capability that is always 
demonstrable. Steps required to demonstrate a new step must 
be implemented and integrated prior to the integration of the 
new step. In terms of subroutines, this means that for a partic- 
ular step, those subroutines that arc required for invoking a 
particular segment of that step must be implemented as part 
of that step or as part of a prior step. In order words, the 
design must be implemented in a top down sequence along 
each branch of the subroutine hierarchy. Lower level sub- 


routines that are not required for demonstration of the partic- 
ular step are to be left as stubs until a step requiring those 
subroutines is undertaken. 

One final aspect of importance is that the steps must fit 
together to comprise functional paths of the system. In 
actuality, to create the NDF, the functional paths are defined 
first, and the paths are then broken down into a sequence of 
steps. Each path corresponds to a relatively independent (but 
not necessarily totally independent) major function of the 
operational system. 

As an example, the Telemetry Path of the SPT NDF is 
shown in Fig. ?. The Telemetry Path itself consists of a main 
path, a long loop path, and an Automatic Total Recall Sub- 
system (ATRS) path. For ease of reference, each step is given a 
number, preceded by a path identifier. Increments of 10 are 
used to allow insertion of additional steps, should this prove 
necessary because of changing requirements or priorities. 
Dashed lines between paths imply dependencies; with respect 
to Fig. 2, implementation of the ATRS path is dependent 
upon completion of the capability to accept directives. 

VIII. Software Status Report 

The Software Status Report tics the Subroutine Hierarchy 
and the NDF together by relating the design elements to the 
demonstrable steps. This is the fundamental point from which 
the value of the Software Status Report, and even the SPT 
Implementation methodology, is derived. The Software Status 
Report meaningfully relates the design to demonstrable 
functions and the corresponding schedules. 

In concept, the document Is very simple. For each step 
from the NDF, the corresponding required subroutines from 
the hierarchy are lisied. Each subroutine is allocated to a 
single step, the first step from the NDF that requires the par- 
ticular subroutine. Consequently, the subroutines listed under 
a particular step are just those subroutines still required for 
demonstration of the particular step's function. Other sub- 
routines may also be required for the step, but they would 
not be listed with the step if some prior step already required 
the subroutines. For status tracking purposes, columns are 
provided where design, code, documentation, test size and 
other status fields can be checked off for each subroutine. 
These fields will be recorded as complete or will contain the 
date set for completion. No attempt is made to allow per- 
centage estimates of completion by the programmer. Statisti- 
cal data provided in the Software Status Report is based on 
treatment of individual segments as statistical equivalents. 
In addition, the Software Status Report includes a description 
of each step. i.e.. the function that is being demonstrated by 
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the particular step. The report also identifies the qualifications 
or limitations, if any, that apply to the step's demonstration 
and the requirements that the step fulfills. 

Whereas in concept the Software Status Repor^ is very 
straightforward, creation of the report requires a thorough 
functional understanding of the system and of the corres- 
ponding design as represented by the Subroutine Hierarchy. 
Only with such knowledge as a base could the programming 
staff hope to allocate specific subroutines to each NDF step. 

Thus, the Software Status Report contains all of the 
steps from the NDF and all of the assigned subroutines from 
the hierarchy, along with the development status for each sub- 
routine and step. With automated support, highly objective 
status reports are easily generated from this data base. Tech- 
nical and administrative management are provided accurate 
visibility into the status of the total software development. 

Figure 3 shows the Software Status Report for a typical 
step from the SPT Implementation Plan. Fig. 4 provides a 
brief description of each of the fields on the report. Fig. S 
contains a Management Summary for one of the paths on 
the SPT NDF. 


IX. Summaiy 

The SPT approach to top down implementation planning 
is based on certain premises. One of these premises is that by 
minimiring or eliminating large unknowns, management has 
the best chance of accomplishing the project's goals. If there 
is some large functional area for which management has little 
basis, other than someone’s intuition, for expecting the imple- 
mentation to take say six months, with a particular size staff, 
as opposed to say three years, then the project is ii^ a precari- 
ous position. A large nebulous function which has onJy been 
quantified at its toial level by intuition, even though based on 
experience, is a dangerous unknown. The obvious way to get 
better control of a big unknown is by reducing it to mariv 
small pieces, some of which may be small unknowns. To put 
it in other terms, analyzing the task and breaking it down into 
many smallei pieces eliminates the risk of the large unknowns. 
There may stiU be some unknowns or surprises, but the poten- 
tial absolute; effect of a misjudgement relative to a small task 
is going to be inherently smaller than for a misjudgement 
associated with the much larger original task. An important 
additional aspect is that in the process of decomposing the 


original function, understanding ocoirs, and for the most part, 
comprehension replaces intuition. 

Also, by decomposing a system into a large number of 
small pieces, a point is reached where the individual pieces can 
be treated for planning purposes as statistically equivalent. At 
the management level, the differences in size or complexity of 
individual small subroutines is of minimal importance. As sub- 
routines are implemented, actual data should be used to up- 
date the estimated statistical characteristics of the average sub- 
routine. For example, suppose an original memory allocation 
of 128K is made for 2000 subroutines. This averages 64 mem- 
ory cells per subroutine. Suppose, after 200 subroutines have 
been implemented, 15000 cells have been used. This would 
riiow an actual avenge of 75 cells per subroutine with the 
trend total being 150K for all 2000 subroutines. Thus, with 
only 10% of the segments implemented, a reliable danger 
signal has been raised, and the signal includes the m^nitude 
of the forecasted overrun. With such an early warning, manage- 
ment still has time to take some appropriate effective action 
to act upon the issue before it becomes an actual problem. 

The key basis for planning and tracking the implementation 
is assigning the impleme** ation of each subroutine to a single 
step. This is where it all ^omes together. But it must be done 
with a great deal of care and precision. The correlation be- 
tween the Subroutine Hierarchy and the Software Status 
Report must be accurate. When design or plan changes occur, 
and they will, changes must be made to both documents. 
Both of these documents riiould be looked upon as evolving 
documents, but they must evolve concurrently and in parallel. 

Why does this '"single step" premise form the basis to the 
SPT approach to implementation planning? Because every- 
thing is accounted for. Each subroutine appears for implemen- 
tation on only one step - the Prst step that requires the sub- 
routine. The effort required for e.!ch step can be considered 
to be a function of the number of subroutines in the step. The 
programming implementation budget can be spread over the 
steps in proportion to the number of segments in each step. 
Then, if you are on schedule, you are on budget. Subroutines 
don’t appear redundantly (on more than one step) to confuse 
the bookkeeping. Everything balances and all subroutines are 
ab'e to be tracked. A full decomposition of the system into 
subroutines and a careful and complete assignment of those 
subroutines to a series of well-defined, demonstrable steps is 
of fundamental importance to successful usage of the SPT 
methodology. 
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1 

2 

SYMBOLIC NAME 
3 4 5 6 7 8 9 * 

DESCRIPTIVE NAME 

CLASS 

/STEP 

LINE 

NUM 

REFER 

NUM 




. CSTMAC 

active mode predictor 

C90 

287 





. . CDBCOM 

DOUBLE INTEGER COMPARE 


288 

♦7 




. . CSHDGB 

HSD BIT ACQUIRE 


289 





. . CDBADD 

DOUBLE INTEGER ADD 


290 





. . CSTMEV 

EVENT PREDICTOR 

C50 

291 





. . . CDBADD 

DOUBLE INTEGER ADD 


292 

277 




. . . CSHDGB 

HSD BIT ACQUIRE 


293 

195 




. . . CDBSUB 

DOUBLE INTEGER SUBTRACT 


294 

284 




. . . CDBCOM 

DOUBLE I’‘:TEGER COMPARE 


295 

197 




CSRCRP 

RECALL QUEUE RESPONSE PROC. 

C90 

296 





. CSCHEK 

STATUS CHECK 


297 

258* 




CSSUPD 

SUSPEND RESPONSE PROC. 

C13C 

298 





. CSTMSU 

MODEL RE ADJUST 

C130 

299 





. . CDBCOM 

DOUBLE INTEGER COMPARE 


300 

197 




. . CDBADD 

DOUBLE INTEGER ADD 


301 

277 




. . CDBSUB 

DOUBLE INTEGER SUBTRACT 


302 

284 




CSCCLO 

CONTROL CENTER RESPONSE PROC. 

C60 

303 





. CSJDGB 

HSD BIT ACQUIRE 


304 

195 




. CSC!- IK 

STATUS CHECK 


305 

258* 




CSMOtP 

MODE CHANGE RESPONSE PROC. 

Cl 00 

306 





. CSMOGB 

HSD BIT acquire 


307 

195 




. CHXASC 

HEX TO ASCII CONV. 


308 

217 




. GEFMSG 

DISPLAY EVENT MESSAGE 


309 

31 




. CSCHEK 

STATUS CHECK 


310 

258* 




. CSTIRM 

RADIATION TIME TEST 


311 

281* 




CSTWOV 

WINDOW OVERRIDE RESPONSE PROC. 

C120 

312 



ng. 1. Sut'routtrM Hierarchy 
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STEP' 010 Transfer Operatoi Entiy to SYMBIONT 
DESCRIPTION: 

This step provides an operator entered directive to the Symbiont 
INTENT: 

This step demonstrates that an operator entered directive is 
placed in an SSB and entered in the Syml^ont Queue. Ths step 
simulates the eventual LMC, LAN Handler, FIDM to SymbkMit 
interface. This also provides a basic buffer and queue manage^ 
ment mechanism. 


SOURCE: 



AUTHOR: 

A. Spinak 


DUE DATE: 

03/02/82 


COORDINATOR: 

T. GREER 


STATUS: 

DATE 

TYPE 

DSGN RVU: 

02/09/82 

TEAM 

TEST: 

03/11/82 

ACCEPTED 

ANOMALIES: 

NOTES: 

0 



Most or all uf this step's software is in the nature of a tempo- 
rary workaround or Environmental Interface Module (£1M>. To 
prove, the SSB and the Symbiont Queue should be checked. 

No queue boundary conditions will be demonstrated. 


SEGMENTS 

DESCRIPTION 

CL 

DATE 

DESIGN 

PERSON 

ST 

DATE 

CODE 

PERSON 

ST 

QA CMP 

UNES 

SIOINP 

OPERATOR 2 SPT SIMULATION 

1 

02/01/82 

MJB 

• 

02/11/82 

MJB 

* 

* 

21 

SiOPOM 

PARSE OPERATOR MESSAGE 

I 

02/02/82 

MJB 

♦ 

02/11/82 

MJB 

• 

• 

21 

SIOPAK 

PACK CD SSB 

1 

02/03/82 

TO 

• 

02/11/82 

TO 

# 

* 

30 

SIOCBB 

LOAD TEST COMM BUFF BLOCK 

S 








0 

SIOSSB 

LOAD TEST SSB BLOCK 

S 








0 

SIOLNK 

CHANGE LINK ID 

S 








0 

OROtNO 

PLACE nodi: on OUtUE 

1 

02/02/82 

TCG 


02/16/82 

MJB 

* 

• 

51 

ORQINI 

INIT FREE 0 NODL POOL 

1 

02/05/82 

TCG 

• 

02/16/82 

TCG 

* 

* 

14 

OPOPQt 

POP 1 RFl Ot 1 UE NODE 

! 

02/05/82 

MJB 

• 

02/16/82 

TO 

* 


15 

GBI Ot r 

I/I TOOUEUE ENTRY 

1 

02/02/82 

TO 

* 

02/12/82 

TO 

• 

• 

35 

GQIMT 

I/ITOINITOUFULS 

1 

02/04/82 

TO 


02/12/82 

TO 

* 

* 

14 


PUSH 1 REF QUEUE NODE 

I 

02/05/82 

MJB 

* 

02/12/82 

MJB 

• 


16 

SPINIT 

SPT INITIALIZATION 

1 

02/10/82 

TCG 

• 

02/15/82 

TCG 

« 

• 

42 

GB1NI7 

li TO INITIALIZE BUFI LRS 

I 

02/22/82 

MJB 

« 

03/05/82 

TO 


* 

58 

GBPOOL 

I/I TO RELEASE BUFFER 

1 

02/22/82 

MJB 

• 

03/05/82 

MJB 

* 

* 

55 

GfTBlT 

III TO on BUFFER 

1 

02/22/82 

MJB 


03/05/82 

MJB 

«> 

* 

56 


Rg.3. Software status report--8tep 010 
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STEP: NUMBER AND NAME OF THE STEP 
DESCRIPTION: 

DESCRIPTION OI THE SVSTEM FUNCTIONS AND CAPABILITIES IMPLEMENTED IN THIS STEP AND A CONCBE SUMMARIZATION 
OF THE DEMONSTRATIONS TO BE TESTED* (I’PTO 3 UNES) 

INTENT: 

EXPLANATORY INFORMATION THAT IS USEFUL IN INTERniETATION AND COMmEHENSlON OF THE STEP. (UP TO 5 LINES) 
SOURCE REFERENCE TO THE REQUIREMENTS MET BY THIS STEP. 

AUTHOR: ORIGINATOR OF THIS STEP INWJT. 

DUE DATE : DATE WHEN THE STEP WILL BE COMPLETED AND READY FOR ACCEPTANCE. 

COORDINATOR : C(X)RDIN ATOR OF THE IMPLEMENTATION OF THE STEP AT THE DETAIL LEVEL. 

STATUS DATE TYPE 

DSGN RVU DESIGN REVIEW DATE TYPE OF REVIEW (TEAM. CDE OR PROG) 

TEST STATUS DATE TYPE OF TESTING (CHECKOUT OR ACCEPTED) 

(IF TYPE IS BLANK. DATE IS PLANNED DA EE) 

(ELSE DATE IS ACTUAL DATE) 

ANOMALIES. NUMBER OF OUTSTANDING ANOMALIES 

NOTES 

NOTES WHICH WOULD BE HELPFUL IN EXPLAINING THE STEP AND ITS IMPLEMENTATION. (UP TO 5 UNES) 

THE SEGMENT COLUMNS ARE AS FOLLOWS: 

STEP NO STEP NUMBER 

SEGMENTS SEGMENT NAMES 

DESCRIPTION SEGMENT DESCRIPTION 

CL CLASSIFICATION CODE (WMPLEMENT. S-STUB. U-UNDEFINED) 

DESIGN DATE PLANNED DAT! OF DE.S1GN COMPLETION 

DESIGN PERSON INITIALS OF PERSON RESPONSIBLE FOR THE SEGMENTS DESIGN 

DESIGN ST DESIGN STATUS (• II COMPLETED) 

CODE DATE PL \NNED DATE OF CODE COMPLETION 

CODE PERSON INITIALS Of PERSON REISPONSIBLE FOR CODING OF THE SEGMENT 

CODE ST CODE STATUS (• IF COMPLETED OR IE REJECTED) 

QA OA STATUS CODE (• IF ACTEPTED) 

CMP COMPILATION CODE ( • FOR CLEAN COMPILE) 

LINES NUMBER OI LINES IN ACCEPTED SEGMENT 

FI9.4. SoftvMTOttatuBrvpoHdMcrtptlon 
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OHiGlN^ 

OF POOR 


PAQE ^ 
quauty 


STFP 

NUM 

STEP NAME ( 

UNIQ 

CUM 

DESGN 

CODE 

CMP 

TEST 

ACEPT 

DUE 

DATE 

LINES 

COI 

tmtialixe Oomnund Tasii 

16 

16 

0 

0 

0 

0 

0 


0 

C02 
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